Data aligner in reconfigurable computing environment

ABSTRACT

A data aligner in a reconfigurable computing environment is disclosed. Embodiments employ hardware macros in field configurable gate arrays (FPGAs) to minimize the number of configurable logic blocks (CLBs) needed to shift bytes of data. The alignment mechanism allows flexibility, scalability, configurability, and reduced costs as compared to application specific integrated circuits.

TECHNICAL FIELD

The present invention relates in general to data processing systems, andin particular, to mechanisms for aligning data bytes.

BACKGROUND INFORMATION

Data processing systems often require alignment and shifting of byteswithin transmitted digital data. For example, bits or bytes of data mayneed to be right-justified or left-justified on a bus. In networkedenvironments, packet headers from one protocol may be shifted comparedto packet headers from another protocol. Such shifting functions may beaccomplished in reconfigurable computing components such as fieldprogrammable gate arrays (FPGAs). Configurable logic blocks (“CLBs”)within an FPGA may be configured into multiplexors that can be used forshifting functions. However, such implementations may be difficult toscale and require a great deal of CLBs, depending on the width of thedata. Thus, there is a need in the art for mechanisms that allowscalability in data alignment functions implemented in reconfigurablecomputing environments such as FPGAs.

SUMMARY OF THE INVENTION

The present invention addresses the above issues by providing mechanismsfor providing scalability in data alignment functions implemented inFPGAs.

An embodiment of the present invention is a network processor systemhaving a field programmable gate array (FPGA). The FPGA includes ahardware multiplication macro and a plurality of configurable logicblocks (CLBs). The network processor system includes a multiplierconfigured from the hardware multiplication macro. The multiplier iscoupled to a plurality of multiplexors that receive a digital signalfrom an input. The digital signal includes a sequence of data bytes. Thenetwork processor system includes a control element operatively coupledto the multiplier and operatively coupled to the plurality ofmultiplexors. The plurality of multiplexors are configured from theplurality of CLBs and coupled to an output. The multiplier receives thedigital signal and the control element signals the multiplier and theplurality of multiplexors to shift the digital signal to result in analtered sequence of data bytes at the output.

The foregoing has outlined rather broadly the features and technicaladvantages of the present invention in order that the detaileddescription of the invention that follows may be better understood.Additional features and advantages of the invention will be describedhereinafter which form the subject of the claims of the invention.

BRIEF DESCRIPTION OF THE DRAWINGS

For a more complete understanding of the present invention and itsadvantages, refer to the following description taken in conjunction withthe accompanying drawings, in which:

FIG. 1 illustrates a hardware environment for practicing an embodimentof the present invention;

FIG. 2A illustrates an IPv4 Ethernet header that may be aligned inaccordance with an embodiment of the present invention;

FIG. 2B illustrates the IPv4 Ethernet header from FIG. 2A aligned forcompatibility with Ethernet 802.1q VLAN in accordance with an embodimentof the present invention;

FIG. 3A illustrates a multiplexor-based alignment scheme that employsabout 64 configurable logic block (CLBs) from a field programmable logicarray (FPGA);

FIG. 3B illustrates the depth of multiplexors from FIG. 3A for handling8-bit bytes, 4 bytes wide;

FIG. 4 illustrates a multiplexor-based alignment similar to that in FIG.3A and configured to handle 8-bit bytes, 8 bytes wide to require about256 CLBs from an FPGA;

FIG. 5A illustrates an embodiment of the present invention whichutilizes FPGA hardware macros for shifting an input and therefore onlyrequires about 14 CLBs;

FIG. 5B illustrates that the multiplier in FIG. 5A has depth forhandling 8-bit bytes, 8 bytes wide; and

FIG. 5C further illustrates the alignment function of the circuit fromFIG. 5A by showing the shifting of individual bytes of an input as theinput progresses through the multiplier to the output.

DETAILED DESCRIPTION

In the following description, numerous specific details are set forthsuch as specific data bit lengths, byte lengths, multiplexor sizes,interface alignment patterns, etc. to provide a thorough understandingof the present invention. However, it will be obvious to those skilledin the art that the present invention may be practiced without suchspecific details. In other instances, well-known circuits have beenshown in block diagram form in order not to obscure the presentinvention in unnecessary detail. Some details concerning timingconsiderations, detection logic, control logic, and the like have beenomitted inasmuch as such details are not necessary to obtain a completeunderstanding of the present invention and are within the skills ofpersons of ordinary skill in the relevant art.

Data realignment functions are often needed in data flow logic of anetworking chip. When a networking chip is implemented in FPGAtechnology, the data realignment function may be implemented with datamultiplexors using configurable logic blocks (“CLBs”). Increasing thespeed of networks may require wider data paths. Wider data pathstranslate into more alignment cases that require more multiplexors. Withsome schemes, increasing the width of data paths requires multiplexorswith more inputs. Implementing such schemes for data realignment withFPGA technology may be difficult because it requires a large number ofCLBs. In addition, such schemes may require an increased amount ofprogrammable wiring resources. Therefore, some FPGA methods of dataalignment may be difficult to scale to allow for increasing data pathwidths.

Embodiments of the present invention use hardware macros within an FP GAfor accomplishing data alignment and data shifting. Using hardwaremacros within the FPGA reduces the need to use the FPGA's CLBs. Usingthese hardware macros rather than reconfiguring CLBs within an FPGA canbe more efficient and economical. Also, using the hardware macros may beadvantageous over designing and developing ASICs (application specificintegrated circuits) for aligning data. Implementing circuits in FPGAsinstead of ASICs can be advantageous when the flexibility of FPGAs isneeded, when the very high density of ASICs is unnecessary, and when thelower design cost of FPGAs is important. Using hardware macros in FPGAscan be a way to make the FPGA design more dense, which, in turn, makesit less expensive. The hardware macros within the FPGA do not consumeCLBs and, instead, only occupy a limited silicon area on the FPGA chip.

Refer now to the drawings wherein depicted elements are not necessarilyshown to scale and like or similar elements may be designated by thesame reference numeral through the several views.

FIG. 1 illustrates a functional block diagram for a Network Processor100 which implements principles for data alignment in accordance with anembodiment of the present invention. Egress MAC (media access control)116 and Ingress MAC 114 move data between Network Processor 100 andexternal physical-layer devices (not shown). Egress MAC 116 and IngressMAC 114 can have numerous data mover units (DMUs, not shown) that can beconfigured independently as an Ethernet MAC or a POS interface. If a DMUis configured for Ethernet, it may support 1 Gigabit Ethernet, 10Gigabit Ethernet, Fast Ethernet, or other such protocols. If a DMU isconfigured for POS mode, it may support OC-3c, OC-12, OC-12c, OC-48,OC-192c, OC-192, and other such protocols. Alternatively, NetworkProcessor 100 may be configured to support different protocols such asIP, IPX, SONET, ATM, Frame Relay, etc. The hardware structures andexample protocols listed are not meant to limit the subject matter ofthe claims, but instead are included to provide context for thedescription herein.

Ingress Dataflow (DF) 106 interfaces with Ingress. MAC 114 to receivepackets from physical devices (not shown) over input 122. The Ingress DF106 collects the packet data in memory (not shown). Upon receivingsufficient data (e.g., the packet header), Ingress DF 106 enqueues thedata to Embedded Processor Complex (EPC) 104 for processing. Once EPC104 processes the packet, it provides forwarding information to IngressDF 106. Ingress DF 106 then invokes flow-control mechanisms (not shown)and either discards the packet or places it in a queue to awaittransmission through Switch Fabric 102. Packets sent from Ingress DF 106to Switch Fabric 102 may flow through a switch interface or other suchhardware, which is omitted for clarity. Network Processor 100 may alsoinclude an “internal wrap” (not shown) that enables traffic to movebetween the Ingress DF 106 and Egress DF 108 without going throughSwitch Fabric 102.

Egress DF 108 interfaces with EPC 110, Egress MAC 116, and Switch Fabric102. Packets received from Switch Fabric 102 are passed to Egress DF108. Egress DF 108 collects the packet data in memory (not shown). TheEgress DF 108 enqueues the packet either to the Egress Scheduler 118 orto a queue for transmission to Egress MAC 116. Egress DF 108 invokesflow-control mechanisms (not shown).

In an embodiment, EPC 104 and EPC 110 perform all processing functionsfor Network Processor 100. In general, the EPCs accept data forprocessing from DFs 106 and 108. The EPCs 104 and 110 determine whatforwarding action is to be taken on the data. The data may be forwardedto its final destination or maybe be discarded. Each EPC may contain oneor more Protocol Processor Units (PPU), such as PPU 124. PPU 124 maycontain multiple processors, coprocessors, and hardware accelerators,which support functions such as packet parsing and classification,high-speed pattern search, and internal chip management. PPU 124 mayinclude one or more general data handlers (GDH), such as GDH 126, andone or more guided frame handlers (GFHs), such as GFH 128. GDH 126 andGFH 128 handle and forward packets for PPU 124 on behalf of EPC 110. Inaccordance with an embodiment of the present invention, Egress DF 108 isimplemented in FPGA and performs data realignments as requested by PPU124. Embodiments of the present invention using FPGAs and associatedmacros make it possible to easily configure and reconfigure componentsto allow compatibility with a range of existing and emerging protocolswithout the expense associated with ASICs.

FIG. 2A illustrates Header 200 for a TCP IPv4 Ethernet IP (InternetProtocol) packet that can be aligned in accordance with principles ofthe present invention. For clarity and ease of identification, variousfields in Header 200 are shown staggered from each other. Header 200 hasa Layer 2 (L2) header 201 containing control information related to theEthernet frame exchanged on a communication link. There are severalvariations of Ethernet networks, and correspondingly, several variationsof L2 headers. Header 201 is a simple L2 header, corresponding tooriginal Ethernet without options.

Header 200 contains a MAC DA field 202 which contains a destinationaddress and 6 bytes (48 bits). MAC SA field 204 contains the sourceaddress and is 6 bytes (48 bits). Ethernet Type field 206 contains 2bytes of identification information regarding the type of packetencapsulated in the Ethernet frame.

Layer 3 (L3) header 208 contains control information related to the IPpacket encapsulated in the Ethernet frame. There are several optionalfeatures defined in IP networking; therefore, there are severalvariations of L3 headers. Layer 3 header 208 is an example of a simpleL3 header, or one without IP options. Version field 210 contains 4 bitsof version information that indicate the version of IP packet. HL field212 contains 4 bits of information regarding the IP header length. TOSfield 214 contains 8 bits of “type of service” information includingpriority information associated with the IP packet. IP Total Lengthfield 216 contains 2 bytes of information on the length of the completeIP packet. Identifier field 217 is a 2 byte number associated with theIP packet. FLG field 218 contains 4 bits of flag information used tocontrol a fragmentation mechanism. Fragmentation Offset field 220contains 2 bytes used to indicate the position of an IP fragment in anoriginal IP packet. TTL field 222 contains 8 bits of “time to live”information and is the number of routers that the IP packet can stillcross. Protocol field 224 contains 8 bits used to identify the type ofdata encapsulated in the IP packet. Header Checksum field 226 contains 2bytes used to detect errors in the received header. IP SA field 228contains 4 bytes related to the IP source address. IP DA field 230contains 4 bytes related to the IP destination address. Note that IP DAfield 230 extends from the second quad word of header 200 to the thirdquad word of header 200.

Layer 4 (L4) header field 232 contains control information related tothe TCP segment (piece of data) encapsulated in the IP packet. There areseveral optional features defined in TCP/IP networking. Correspondingly,there are several variations of L4 headers. Layer 4 header field 232represents a simple variation of L4 header. SP field 234 contains 2bytes of source port data used to identify the source of the TCPconnection in the IP source. DP field 236 contains 2 bytes ofDestination Port information related to identification of thedestination of the TCP connection in the IP destination. Sequence Numberfield 238 contains 4 bytes used to identify the position of the TCPsegment in the stream of TCP data. Ack Number field 240 contains 4 bytesused to identify the position of the latest data correctly received. HLfield 242 contains 4 bits representing the header length. CB field 244contains 6 Code Bits. Windows field 258 contains 2 bytes that indicatethe position of the acknowledgement window. TCP checksum 260 contains 2bytes used to detect errors in the complete TCP segment. Urgent Pointerfield 262 contains 2 bytes used to indicate the position of urgent data.The payload of the Ethernet frame appears after L2 header 201, L3 header208, and L4 header 232.

FIG. 2B illustrates header 268 for a TCP IPv4 Ethernet packet under theIEEE specification 802.1q VLAN. Like-numbered items in FIGS. 2A and 2Bcorrespond. Similar to header 200 (FIG. 2A), header 268 is an IP packetheader. FIGS. 2A and 2B illustrate headers that are carried on 16-bytewide data paths that carry quad words of 16 bytes at each clock cycle.Header 268 differs from header 200 by the L2 header. Specifically,compared to L2, header 201, L2 header 270 is another variation of anEthernet header that contains 4 additional bytes to support the VLANoption (Virtual Local Area Network). Other additional fields in header268 (FIG. 2A) include TCI field 272, which contains tag controlinformation and Ether Type field 273.

Comparing header 200 and header 268 (FIG. 2B), corresponding headerpositions in header 268 are “pushed” by 4 byte positions starting withthe Ethernet type field 206 (FIG. 2A). In header 268, the Ethernet typefield 206 (FIG. 2A) originally in quad word #1 byte positions 12-13 ispushed to quad word #2 byte positions 0-1 (FIG. 2B). This shift can beaccomplished using principles of the present invention that utilizeconfigurable FPGAs that contain multiplication macros that can be usedfor shifting header 200 to result in header 268.

FIG. 3A illustrates a multiplexor-based data Realigner 300. Input 310feeds 4-byte wide, 4:1 MUXs that collectively form MUX Bank 308. Forexample, four byte lines (shown as item 304) from Input 310 feed thefour inputs of MUX 306. FIG. 3B illustrates a detail view of MUX 306,which shows that Realigner 300 handles a thirty-two bit word on 4-byteboundaries. Control Element 302 provides a control signal to MUX 306that selects which line from Input 310 is sent to Output 312. In thisway, Control Element 302 can shift Input 310 and provide the desiredsignal at output 312. As shown, Realigner 300 is four bytes wide. Asshown in FIG. 3A, Realigner 300 requires approximately sixty-four CLBsto implement the MUXs required to implement the equivalent of thirty-two4:1 MUXs needed for item 308. As discussed below embodiments of thepresent invention require fewer CLBs.

FIG. 4 illustrates a multiplexor-based data Realigner 400 similar toRealigner 300 (FIG. 3A). Input 402 is made of eight bytes that are eightbits deep. Control element 408 controls outputs from MUXs in MUX Bank404 to achieve a realigned version of Input 402 at Output 406. Realigner400 is an 8-byte wide realigner that is based on thirty-two bit words onbyte boundaries. Using 8:1 MUXs for MUX Bank 404, Realigner 400 wouldemploy about 256 CLBs in an FPGA. As shown in FIG. 5A, embodiments ofthe present invention may utilize multiplication macros to achieveshifting to allow using much fewer than 256 CLBs to achieve a moreefficient realigner than Realigner 400 shown in FIG. 4.

FIG. 5A illustrates an FPGA-based Realigner 500 which operates inaccordance with the present invention. Input 504 is eight bytes wide andeight bits deep. Control Element 502 controls Multiplier 506 and theMUXs within MUX Bank 508. As shown in FIG. 5B, Multiplier 506 representseight 8×8 multipliers that, in accordance with one embodiment of thepresent invention, are implemented using hardware macros within an FPGA.For example, Multiplier 506 could be implemented using a multiplicationmacro in a Virtex™ II FPGA provided by Xilinx™. If Control Element 502sends a signal to Multiplier 506 to multiply by 2, Multiplier 506 shiftsthe signal on Input 504 by one position. In addition, to achieve a“wrap-around” function, Control Element 502 may signal the MUXs withinMUX Bank 508 to replace the LSB (least significant byte) with the MSB(most significant byte). This results in a realigned version of Input504 at Output 510.

As shown in FIG. 5A and FIG. 5B, Multiplier 506 consists of hardwaremultiplier macros that may consume no CLBs. Accordingly, Realigner 500can be implemented using only about fourteen CLBs for the 7-byte-wide,2:1 MUXs in MUX Bank 508. This approximately fourteen CLBs required byRealigner 500 is significantly less than the approximately 256 CLBsrequired by the MUX-based Realigner 400 (FIG. 4A). Therefore, Realigner500 utilizes FPGA hardware macros to reduce the number of FPGA CLBsrequired to implement a data realigner.

FIG. 5C illustrates Realigner 500 from FIG. 5A used to shift a signal onInput 504 by five positions. Like-numbered items in FIGS. 5A, 5B, and 5Ccorrespond. The first three bytes of the signal on Input 504 are shownsimilarly hatched as item 514. The last five bytes of the signal onInput 504 are similarly hatched as item 512. Input 504 is coupled toMultiplier 506. Control Element 502 signals Multiplier 506 to multiplyby 32, which accomplishes a shift of five positions. Multiplying by 32is equivalent to shifting five positions, since 2 taken to the fifthpower equals 32. As shown in FIG. 5C, the first five positions (1-5) ofthe output of Multiplier 506 are not passed through to the outputs ofMUX Bank 508. Instead, output positions 6-13 are used from Multiplier506. Output positions 6-8 are used for outputting item 514 and Outputpositions 9-13 are used for outputting item 512. Correspondingly,Control Element 504 signals the MUXs in MUX Bank 508 such that item 514are output as Realigned Bytes 6-8 at Output 510. In addition, ControlElement 504 signals the MUXs in MUX Bank 508 such that item 512 isoutput as Realigned Bytes 1-5 at Output 510. In this manner, Realigner500 can be used to shift an 8-byte wide input by five positions usingonly about fourteen CLBs in an FPGA. Rather than using more than aboutfourteen CLBs to accomplish such shifting, Realigner 500 uses hardwaremacros that are integral to the FPGA. This reduces costs, simplifieswiring requirements, and allows configurability that allow a developerto account for emerging needs.

Although the present invention and its advantages have been described indetail, it should be understood that various changes, substitutions, andalterations could be made herein without departing from the spirit andscope of the invention as defined by the appended claims.

1-15. (canceled)
 16. A system comprising: an egress dataflow utilizing afield programmable gate array (FPGA), wherein the FPGA is operable toprovide a multiplication macro; and a control element operativelycoupled to the egress dataflow, wherein the egress data flow utilizesthe multiplexor macro to shift a plurality of data bytes of an incomingdata packet to result in an outgoing data packet.
 17. The system ofclaim 16, wherein the egress dataflow shifts the plurality of data bytesin response to the control element.
 18. The system of claim 16, whereinthe incoming data packet comprises a first header formatted for a firstprotocol, wherein the outgoing data packet comprises a second headerformatted for a second protocol.
 19. The system of claim 17, wherein thecontrol element is a protocol processor unit (PPU).
 20. The system ofclaim 19, wherein the incoming data packet contains a first datapayload, wherein the outgoing data packet contains a second datapayload, wherein the first and second data payloads correspond, whereinthe outgoing data packet contains an additional header field notcontained in the incoming data packet.